<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'Considering options',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<img src="/img/CC_BY-SA_4.0/y.st./weblog/2018/12/28.jpg" alt="A crossing on my way to work" class="framed-centred-image" width="649" height="480"/>
<section id="drudgery">
	<h2>Drudgery</h2>
	<p>
		My discussion post for the day:
	</p>
	<blockquote>
		<h3>Part 0: $a[FIFO]</h3>
		<p>
			The term first in, first out should be familiar.
			A $a[FIFO] buffer pool is a queue (Shaffer, 2011)!
			Or rather, in some ways, it operates like one.
			You can access data in any part of the buffer pool, unlike in a queue, but like in a queue, data is removed from the buffer pool in the same order it was added in.
		</p>
		<p>
			This strategy isn&apos;t efficient when data is to be retrieved in cycles that are bigger than the buffer pool size.
			It&apos;s also not efficient when there&apos;s data that gets used regularly along with something that pulls data from several locations on disk.
			For example, maybe you need pages in this order: 0, 1, 0, 2, 0, 3, 0, 4, 0, 5, 0, 6, 0, 7, 0, 8, 0, 9, 0.
			Obviously, you shouldn&apos;t be removing page zero from the buffer pool, as you use it over half the time.
			However, a $a[FIFO] buffer would remove and re-add page zero a few times by the time you completed your work.
		</p>
		<p>
			$a[FIFO] buffers seem to work well when you don&apos;t need access to many pages at once.
			Once you finish with the pages you&apos;re working with, you move on to another few, and the old ones you&apos;re no longer working with get removed from the buffer pool.
		</p>
		<h3>Part 1: $a[LRU]</h3>
		<p>
			A $a[LRU] buffer kicks out pages that were the least-recently used.
			The theory behind it is that if you&apos;re still using a page, it&apos;s not going to be the one you accessed last.
		</p>
		<p>
			I&apos;m not seeing any real drawback to this sort of buffer pool, unless you have special knowledge of how the pages will be accessed.
			And in most cases, you don&apos;t.
			In particular, this buffer can be used to avoid disk writes unless absolutely necessary (Shaffer, 2011).
			Writes can be put off until it seems as much data as will be written has been finalised.
			Any time the data is used again, it gets brought back to the beginning of the queue, so it doesn&apos;t get removed from the buffer pool.
		</p>
		<h3>Part 2: $a[LFU]</h3>
		<p>
			A $a[LFU] buffer replaces whatever data is least-frequently used.
			This method has more overhead, as the buffer pool has to keep track of how many times each page gets used (Shaffer, 2011).
			This method is a nice upgrade from $a[FIFO] buffer pools, but like anything, it still has disadvantages.
			If a page gets used repeatedly, its use count can go up, but the page still can become irrelevant eventually.
			If the use count is too high, it can take a while for the page to eventually dropped.
			In fact, it may never be, if other pages can&apos;t build up a higher use count.
			This effect can be mitigated with a page expiration system.
			For the most part though, this method provides the advantage that if a page is still being used frequently, it&apos;s highly unlikely to be removed from the buffer pool.
			When working with a small number of frequently-used pages and any number of infrequently-used pages, this buffer pool strategy performs correctly, removing the pages from the pool that won&apos;t be needed again for a while.
		</p>
		<p>
			When pages are not repeated in the list of what pages are accessed, this strategy doesn&apos;t perform well.
			But then again, what strategy <strong>*would*</strong>?
			The point of the buffer pool is that data being accessed doesn&apos;t have to be read from/written to disk as many times.
			But if entirely different parts of the disk are accessed, buffers aren&apos;t going to help reduce read/write counts.
		</p>
		<p>
			On the other hand, when page accesses <strong>*do*</strong> get repeated, the use count of those pages goes up, and those pages don&apos;t get removed from the buffer pool.
			In that case, future access to those pages will be faster, because no disk {$a['I/O']} will be needed.
		</p>
		<div class="APA_references">
			<h3>References:</h3>
			<p>
				Shaffer, C. (2011). A Practical Introduction to Data Structures and Algorithm Analysis. Retrieved from <a href="https://my.uopeople.edu/pluginfile.php/356474/mod_page/content/2/Practical_Into_to_Data_Structures_and_Algorithms_-_Shaffer.pdf"><code>https://my.uopeople.edu/pluginfile.php/356474/mod_page/content/2/Practical_Into_to_Data_Structures_and_Algorithms_-_Shaffer.pdf</code></a>
			</p>
		</div>
	</blockquote>
</section>
<section id="Minetest">
	<h2>Minetest</h2>
	<p>
		Planning for the spell-casting mod continues.
		I think instead of the stats determining the maximum amount of spell energy you can store, I want to instead use the stats to determine the rate at which the energy recharges.
		That way, instead of pressuring players into using the energy from their weak stats quickly, it&apos;ll reward them for making their stats strong.
		There will still be an energy cap, but it&apos;ll be so high that anyone regularly casting spells won&apos;t need to worry about it, and that cap won&apos;t change as stats rise.
		At least for most spells.
		I think the cap on spell energy will be the maximum stack size of the item that grants the spell, and one point of spell energy will be granted whenever a number of mining ticks equal to the maximum stack size of the elemental item have been mined.
		Mining ticks occur any time you trigger a stat change by mining, but are not equal to the number of dropped items.
		For example, if you dug a single cotton plant and it dropped three seeds, three strings, and two cotton, that wouldn&apos;t be eight mining ticks; it&apos;d only be one, because you only dug one node that dropped countable items.
	</p>
</section>
<section id="vasectomy">
	<h2>Vasectomy</h2>
	<p>
		I don&apos;t know why, but I thought a lot today about something the vasectomy surgeon told me.
		I&apos;d made it abundantly clear that I didn&apos;t want anything to do with females if I couldn&apos;t guarantee that I wouldn&apos;t make them pregnant.
		They told me that there were other things we could do in bed besides penile-vaginal intercourse.
		I didn&apos;t take it seriously at the time.
		I mean, I didn&apos;t think a female that would be attracted to me wouldn&apos;t be into standard sex.
		She might be into all sorts of other things too, but for some reason, I thought she wouldn&apos;t put up with a lack of regular sex.
		I mean, if I was with a male, I know <strong>*I&apos;d*</strong> want him to put his penis in me and fuck me.
		Then again though, I&apos;d want that from a female too; if she&apos;s not willing to put on a strap-on, that just might be a deal breaker.
	</p>
	<p>
		Anyway, supposing there <strong>*is*</strong> a female that liked me enough to try other things instead?
		And what if she was someone with a great personality and someone I enjoyed spending time with?
		I&apos;m starting to think maybe I shouldn&apos;t rule out females just yet, just in case.
		If I do go that route, it would in fact be good to get the vasectomy.
		If all goes well, it wouldn&apos;t have an effect, but if it turns out I misjudged her, she might pull something bitchy like inserting my already-expelled seamen into herself.
		The vasectomy should prevent that one possible pregnancy, after which she wouldn&apos;t get a second chance.
		After that sort of betrayal, I&apos;d wait to make sure there was no baby, but after that, we&apos;d be over.
	</p>
	<p>
		I still have time to think though.
		It&apos;s not like I have time for relationships while I&apos;m still attending this draining school.
		I&apos;m not the type to take sex lightly, so there won&apos;t be any sex in the mean time.
		There's no need to rush into a vasectomy now that won't do a bit of good for at least two years.
	</p>
</section>
END
);
